home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 342 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB
  1. From: ajay@lehman.com (Ajay Kamdar)
  2. Message-ID: <4fdsql$e6m@jabba.lehman.com>
  3. X-Original-Date: 8 Feb 1996 17:17:57 -0500
  4. Path: in1.uu.net!bounce-back
  5. Date: 09 Feb 96 15:35:59 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Make type_info name() distinct?
  9. Organization: Lehman Brothers, Inc.
  10. References: <v01530500ad36a19a2831@[194.163.74.11]> <199602030146.RAA14333@shellx.best.com> <xsorawcazry.fsf@avs.cs.rpi.edu>
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMRtqH+EDnX0m9pzZAQGtEQF/QvZvHK4UTt9D2zWAUTR+Nt6d62YNSJWd
  13.     rYwqliOWPEZL3iqNu7qOik4BQPBBlfYe
  14.     =Fu62
  15.  
  16. In article <xsorawcazry.fsf@avs.cs.rpi.edu>,
  17. David Vandevoorde <vandevod@cs.rpi.edu> wrote:
  18. >
  19. >>>>>> "BG" == Bill Gibbons <bgibbons@best.com> writes:
  20. >[...]
  21. >BG> There is some chance that some canonical form will be recommended
  22. >BG> in a non-normative annex in the standard.
  23. >
  24. >There was a thread here some time ago concluding that RTTI would be
  25. >considerably more convenient for purposes of object persistence and 
  26. >transportation if this could be standardized somehow.
  27.  
  28. Standardizing the return value of name() helps, but only a little.
  29. RTTI would be considerably more convenient for the purposes of
  30. object persistence and transportation if it also included the
  31. following object layout information:
  32.  
  33.     + Information about data members.
  34.       For each data member, this information would consist of
  35.       # data member typeinfo
  36.       # data member name
  37.       # isAPointer? (number of indirections if yes)
  38.       # isAReference?
  39.       # raw offset from start of immediately containing object
  40.         (This would be of course compiler and platform specific.
  41.          But that is _exactly_ what is required.)
  42.  
  43.     + Information about base classes
  44.       For each base class, this information would consist of 
  45.       # base class typeinfo
  46.       # virtual derivation?
  47.       # raw offset from start of deriving class; offset to 
  48.         the actual sub-object is a virtual base class
  49.  
  50.     + Virtual destructor?
  51.  
  52.  
  53. base classes were
  54.       # access protection (public/protected/private)
  55.       # type of derivation (public/protected/private)
  56.  
  57.  
  58. This list is probably not exhaustive, but would be a good first start.
  59.  
  60. The compiler generates all this meta data for itself, and unfortunately
  61. throws it all away rather than allowing access to it
  62. programmatically. With in the last five years I have worked on three
  63. separate projects where the availability of meta data from
  64. the compiler itself would have saved us very significant amounts of
  65. time and money inventing elaborate meta data generation mechanisms of
  66. our own.
  67.  
  68. I don't remember any discussion in this forum as to why the standards
  69. committee limited RTTI information to its current form. Did the
  70. committee ever consider standardizing more detailed RTTI?
  71. Were there technical problems which prevented such standardization?
  72. -- 
  73. Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
  74. Lehman Brothers    |    Phone: (201) 524-5048     |
  75. ---
  76. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  77.   Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  78.   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]
  79.